Skip to main content

State difference between include and extends.

Differences Between «Include» and «Extend» Relationships in Use Case Diagrams​

Both «include» and «extend» are relationships used in UML use case diagrams to show how use cases interact with each other, but they serve different purposes and have distinct characteristics. The following comparison highlights the key differences between these two relationship types:

Aspect«Include» Relationship«Extend» Relationship
DefinitionA relationship where a base use case incorporates the behavior of another use caseA relationship where a base use case may be augmented by another use case under specific conditions

1. Nature of Behavior​

«Include»​

  • Mandatory behavior: The included use case will always be executed as part of the base use case
  • Essential functionality: Represents behavior that is necessary for the completion of the base use case
  • Core part: Forms an integral part of the base use case's normal flow

«Extend»​

  • Optional behavior: The extending use case may or may not be executed depending on conditions
  • Supplementary functionality: Represents additional behavior that is not essential
  • Alternative or exceptional flow: Often represents special cases or exceptional scenarios

2. Direction of Relationship​

«Include»​

  • Arrow points from the base use case to the included use case
  • Direction indicates that base use case calls or uses the included use case
  • E.g., "Place Order" ──include──> "Validate Credit Card"

«Extend»​

  • Arrow points from the extending use case to the base use case
  • Direction indicates that extending use case adds behavior to the base use case
  • E.g., "Handle Special Discount" ──extend──> "Process Sale"

3. Purpose and Usage​

«Include»​

  • Reuse common functionality: Extract common behavior to avoid duplication
  • Simplify complex use cases: Break down large use cases into more manageable pieces
  • Modularization: Promote modular design by separating distinct responsibilities

«Extend»​

  • Handle variations: Manage alternative flows separately from the main use case
  • Progressive enhancement: Add optional features without modifying the core use case
  • Separate concerns: Keep exceptional or conditional behavior separate from normal flows

4. Control Flow​

«Include»​

  • Base use case has control: The base use case explicitly calls the included use case
  • Predetermined point: Inclusion happens at a specific, predetermined point in the flow
  • Conscious inclusion: Base use case is aware of and deliberately uses the included use case

«Extend»​

  • Extension points control: Extension occurs at specified extension points if conditions are met
  • Conditional execution: The extension only happens if certain conditions are satisfied
  • Transparent extension: Base use case may not be explicitly aware of possible extensions

5. Structural Elements​

«Include»​

  • No extension points: Does not require extension points to be defined
  • No conditions: Does not specify conditions for execution
  • Simple relationship: Typically represented just by the «include» stereotype on the arrow

«Extend»​

  • Extension points: Requires explicit extension points where the extension can occur
  • Conditions: Specifies conditions under which the extension should be executed
  • More complex relationship: Often includes extension points and condition notes

6. Diagram Representation Example​

┌─────────────────────────────────────────────────────────────────┐
│                        System Boundary                           │
│                                                                  │
│   «Include» Example:                     «Extend» Example:       │
│                                                                  │
│   ┌─────────────┐     «include»     ┌─────────────┐             │
│   │             │─────────────────► │             │             │
│   │ Book Flight │                   │ Process     │             │
│   │             │                   │ Payment     │             │
│   └─────────────┘                   └─────────────┘             │
│                                                                  │
│                                                                  │
│   ┌─────────────┐                   ┌─────────────┐             │
│   │             │                   │             │             │
│   │ Check In    │ ◄───────────────  │ Select      │             │
│   │             │     «extend»      │ Seat        │             │
│   │ Extension points:               │             │             │
│   │ - during check-in               └─────────────┘             │
│   └─────────────┘                                               │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

7. Real-World Analogy​

«Include»​

Like required ingredients in a recipe - you cannot make chocolate cake without including the steps for mixing flour, sugar, and cocoa.

«Extend»​

Like optional toppings on a pizza - the pizza can exist without pepperoni, but pepperoni can be added to enhance it under certain conditions (e.g., if the customer requests it).

Understanding the differences between these relationships is crucial for creating accurate and effective use case models that properly represent the functional requirements of a system.